In a telecommunications environment, data transport networks such as Plesiochronous Digital Hierarchy (PDH) networks, Synchronous Digital Hierarchy (SDH) networks or Synchronous Optical NETworks (SONET) are used for transporting data streams from 2 Mbit/s up to 10 Gbit/s, not only for voice, but also for packet data. Such transport networks may form a backbone for interconnecting network nodes in a communications network or between communication networks. The Optical Transport Networks (OTN) may be employed as data transport networks for the higher data rates of 1 Gbit/s up to 100 Gbit/s, which can be achieved based on optical transmission technologies.
The International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) provides recommendation G.709 as the standardization reference for optical data transport networks and interfaces. The G.709 standard specifies the optical transport hierarchy and the interfaces for optical networks of various kinds of network architectures.
The data to be transported for a particular client service will be inserted into transport frames of a suitable hierarchical level depending on the required data rate (bandwidth). However, in general the bandwidth required for a particular client service will not exactly fit to the bandwidth provided for by a particular hierarchical level, i.e. the efficiency of bandwidth usage will be low. In order to provide more efficient use of the available bandwidth, concepts have been developed according to which the client service data are to be inserted into several identical transport frames of a lower hierarchical level. In order to be able to recover the data at the end, the association of the multiple transport frames with each other has to be represented in the data transport network. The related concepts are commonly referred to as “Virtual concatenation” (VCAT) initially developed for SDH, see for an introduction G.709, section 18.
The approach for providing flexible bandwidth connections through an OTN is “ODUflex”, see G.709 amd 3, rev 2. ODUflex supports the transport of circuit-based (CBR, Constant Bit Rate) clients as well as packet-based (GFP, Generic Framing Procedure) clients. The bandwidth of the network ODU (Optical Data Unit) connection can be adjusted according to the bandwidth needs of the client service.
A general problem for any existing connection passing through the data transport network is dynamic resizing, in particular in the case of transporting packet based data. The client service may have a dynamic bandwidth requirement, i.e. the bandwidth requirement varies with time. The serving network connection should be flexibly configured accordingly in a hitless manner, i.e. there should be no packet loss when resizing the connection.
The hitless issue cannot be achieved when considering a very simple solution for resizing, namely terminating, in a first step, an existing connection and initiating, in a subsequent step, a new one (with a different bandwidth). At the time when the first connection is already terminated, but the second connection is not yet active, there will presumably packets be lost for the client service. Invoking the second connection before terminating the first connection leads to a blocking, i.e. waste, of transport resources. Thus, more sophisticated concepts are required for hitless resizing.
In the (SDH) VCAT framework, a concept termed “Link Capacity Adjustment Scheme” (LCAS) has been developed, see G.7402 and for its application in OTN G.709, section 18.3. Using LCAS, the bandwidth of a “connection” represented by multiple virtually concatenated containers (ODUk) can be increased or decreased by adding or removing elements of the Virtual Concatenation Group (VCG).
While the VCAT/LCAS approach provides for flexible bandwidth connections which can be dynamically resized on demand, this comes on the cost of high complexity. For example, the multiple members of the VCG may be transmitted along different paths in the network. Thus, delay compensating buffers are required at the sink (egress) end point of the virtual connection. Further, the LCAS protocol is relatively complex, as, for example, the status of each member has to be sent back from the sink end point to the source (ingress) end point of the virtual connection.